Redis Enterprise DBMS must use centralized management of the content captured in audit records generated by all components of Redis Enterprise DBMS.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-251193	RD6X-00-005300	SV-251193r804769_rule		Medium

Description
Without the ability to centrally manage the content captured in the audit records, identification, troubleshooting, and correlation of suspicious behavior would be difficult and could lead to a delayed or incomplete analysis of an ongoing attack. The content captured in audit records must be managed from a central location (necessitating automation). Centralized management of audit records and logs provides for efficiency in maintenance and management of records, as well as the backup and archiving of those records. The DBMS may write audit records to database tables, to files in the file system, to other kinds of local repository, or directly to a centralized log management system. Whatever the method used, it must be compatible with offloading the records to the centralized system. For more information, refer to: https://docs.redislabs.com/latest/rs/administering/logging/rsyslog-logging/ and https://redislabs.com/blog/sending-redis-cluster-alerts-to-slack-with-syslog/

Description

Without the ability to centrally manage the content captured in the audit records, identification, troubleshooting, and correlation of suspicious behavior would be difficult and could lead to a delayed or incomplete analysis of an ongoing attack. The content captured in audit records must be managed from a central location (necessitating automation). Centralized management of audit records and logs provides for efficiency in maintenance and management of records, as well as the backup and archiving of those records. The DBMS may write audit records to database tables, to files in the file system, to other kinds of local repository, or directly to a centralized log management system. Whatever the method used, it must be compatible with offloading the records to the centralized system. For more information, refer to: https://docs.redislabs.com/latest/rs/administering/logging/rsyslog-logging/ and https://redislabs.com/blog/sending-redis-cluster-alerts-to-slack-with-syslog/

STIG	Date
Redis Enterprise 6.x Security Technical Implementation Guide	2021-11-23

Details

Check Text ( C-54628r804767_chk )
Review the system documentation for a description of how audit records are offloaded and how local audit log space is managed. Redis Enterprise leans on the RHEL host server rsyslog to unify and centralize logs as well as to send them to a centralized log management server or system. To verify that all of the logs are captured in syslog, view the redislabs.conf file in /etc/rsyslog.d. Verify that for each log produced by Redis Enterprise (found in /var/opt/redislabs/log), there is a line in redislabs.conf similar to: if $programname startswith '[Log name found in /var/opt/redislabs/log] ' then { action(type="omfile" file="/var/log/redislabs.log" template="RedisLabsEventTemplate" ) } To verify that Redis Enterprise is configured on the server to send all logs to a centralized log management system, examine the redislabs.conf file found in /etc/rsyslog.d. The file should include the line: action(type="omfwd" protocol="tcp" target="[organization defined logging server IP]" port="[organization defined logging server port]" template="RedisLabsEventTemplate" ) If redislabs.conf is not configured to capture all logs produced by Redis Enterprise or does not exist, this is a finding. If the Redis Enterprise audit records are not written directly to or systematically transfer to a centralized log management system, this is a finding.

Check Text ( C-54628r804767_chk )

Review the system documentation for a description of how audit records are offloaded and how local audit log space is managed. Redis Enterprise leans on the RHEL host server rsyslog to unify and centralize logs as well as to send them to a centralized log management server or system.

To verify that all of the logs are captured in syslog, view the redislabs.conf file in /etc/rsyslog.d. Verify that for each log produced by Redis Enterprise (found in /var/opt/redislabs/log), there is a line in redislabs.conf similar to:
if $programname startswith '[Log name found in /var/opt/redislabs/log] ' then {
action(type="omfile" file="/var/log/redislabs.log" template="RedisLabsEventTemplate" )
}

To verify that Redis Enterprise is configured on the server to send all logs to a centralized log management system, examine the redislabs.conf file found in /etc/rsyslog.d. The file should include the line:
action(type="omfwd" protocol="tcp" target="[organization defined logging server IP]" port="[organization defined logging server port]" template="RedisLabsEventTemplate" )

If redislabs.conf is not configured to capture all logs produced by Redis Enterprise or does not exist, this is a finding.

If the Redis Enterprise audit records are not written directly to or systematically transfer to a centralized log management system, this is a finding.

Fix Text (F-54582r804768_fix)
Configure Redis Enterprise to use syslog for all logs generated. Ensure that redislabs.conf exists and is configured. Create the file as shown here: /etc/rsyslog.d/redislabs.conf The log entries can be categorized into events and alerts. Events are only logged, while alerts have a state attached to them. RS log entries include information about the specific event that occurred. In addition, rsyslog can be configured to add other information, like the event severity, for example. Since rsyslog entries do not include the severity information by default, use the following instructions to log that information (in Ubuntu): Add the following line to /etc/rsyslog.conf $template TraditionalFormatWithPRI,"%pri-text%:%timegenerated%:%HOSTNAME%:%syslogtag%:%msg:::drop-last-lf%\n" And modify $ActionFileDefaultTemplate to use the new template: $ActionFileDefaultTemplateTraditionalFormatWithPRI Save the changes and restart rsyslog for the changes to take effect. The alerts and events may be found under /var/log in messages log file. Command components: %pritext% adds the severity %timegenerated% adds the timestamp %HOSTNAME% adds the machine name %syslogtag% the RS message as detailed below in the Log entry structure section below. %msg:::droplastlf%n removes duplicated log entries Example configuration: template(name="RedisLabsEventTemplate" type="string" string="%syslogseverity-text%:%pri-text%:%timegenerated%:%HOSTNAME%:%syslogtag%:%msg:::drop-last-lf% -- %syslogtag% -- %programname% \n") if $programname startswith 'event_log' then { action(type="omfile" file="/var/log/redislabs.log" template="RedisLabsEventTemplate" ) } With this configuration, the syslog service will: Load a new template named RedisLabsEventTemplate that logs the message with the priority (syslogseverity-text) that will be info, crit, warning, etc. Use this template to write into the file /var/log/redislabs.log when the program is "event_log" (the Redis Enterprise log manager). Learn more about the template syntax in the syslog documentation. Restart syslog: systemctl restart rsyslog Testing the new configuration: Navigate to the Redis Enterprise web console and create a new database (or edit an existing database). There should be a new /var/log/redislabs.log file and the event that was generated.

Fix Text (F-54582r804768_fix)

Configure Redis Enterprise to use syslog for all logs generated. Ensure that redislabs.conf exists and is configured.

Create the file as shown here:
/etc/rsyslog.d/redislabs.conf

The log entries can be categorized into events and alerts. Events are only logged, while alerts have a state attached to them. RS log entries include information about the specific event that occurred. In addition, rsyslog can be configured to add other information, like the event severity, for example.

Since rsyslog entries do not include the severity information by default, use the following instructions to log that information (in Ubuntu):

Add the following line to /etc/rsyslog.conf $template TraditionalFormatWithPRI,"%pri-text%:%timegenerated%:%HOSTNAME%:%syslogtag%:%msg:::drop-last-lf%\n"

And modify $ActionFileDefaultTemplate to use the new template: $ActionFileDefaultTemplateTraditionalFormatWithPRI

Save the changes and restart rsyslog for the changes to take effect. The alerts and events may be found under /var/log in messages log file.

Command components:
%pritext% adds the severity
%timegenerated% adds the timestamp
%HOSTNAME% adds the machine name
%syslogtag% the RS message as detailed below in the Log entry structure section below.
%msg:::droplastlf%n removes duplicated log entries

Example configuration:
template(name="RedisLabsEventTemplate" type="string" string="%syslogseverity-text%:%pri-text%:%timegenerated%:%HOSTNAME%:%syslogtag%:%msg:::drop-last-lf% -- %syslogtag% -- %programname% \n")

if $programname startswith 'event_log' then {
action(type="omfile" file="/var/log/redislabs.log" template="RedisLabsEventTemplate" )
}

With this configuration, the syslog service will:
Load a new template named RedisLabsEventTemplate that logs the message with the priority (syslogseverity-text) that will be info, crit, warning, etc.

Use this template to write into the file /var/log/redislabs.log when the program is "event_log" (the Redis Enterprise log manager). Learn more about the template syntax in the syslog documentation.

Restart syslog: systemctl restart rsyslog

Testing the new configuration:
Navigate to the Redis Enterprise web console and create a new database (or edit an existing database). There should be a new /var/log/redislabs.log file and the event that was generated.